[DWARF Import] Support relocatable objects: section addresses and RISC-V relocations - #8656

Depends on #8654, which this branch is based on. Until it merges, the diff also shows that commit. The two new commits make DWARF import work for relocatable objects (ET_REL).

1. Place object file addresses where the view put their sections

All sections of a .o have address 0, so a DWARF address is an offset into the section its relocation's symbol is in. The importer only added the image base, so anything outside the first section landed at the wrong address:

Change:

• For a relocatable debug file, look up each allocated section in the view by name (size must match; the ELF view's <name>#<index> duplicates resolve too).
• RelocationMap::add adds that section's address to the addend of relocations against its symbols, so relocated DWARF addresses, including .debug_frame, land where the view put the section.
• Linked executables, shared objects, the .gnu_debugaltlink file and dwarfdump get an empty map, so they are unchanged.
• [DWARF Import] Fix addresses for PIE and rebased views, relocatable objects and RISC-V objects #8654 skips rebasing data variables for objects because their addresses were section offsets. They are placed now, so that exception is removed.

-fcommon symbols have no section and are not relocated.

2. Apply RISC-V label-difference relocations

Any RISC-V object built with -g fails with Failed to parse DWARF: Failed to load DWARF info: Unsupported relocation type, because object only accepts absolute relocations in a relocation map. With linker relaxation, GNU as emits pairs at the same offset instead (ADD/SUB 8-64, SET6/SUB6, SET8/SUB8, SET_ULEB128/SUB_ULEB128). They can't go in a map, since SUB* reads what ADD*/SET* wrote.

Change: on RISC-V, RelocationMap::add applies these in file order to a copy of the section data, following the psABI formulas and binutils (perform_relocation; the SUB_ULEB128 addend is ignored, as in binutils PR31179). Errors if a ULEB128 result doesn't fit its encoded length or a SET_ULEB128 isn't followed by its SUB_ULEB128 (Error::RelocationOutOfBounds, Error::InvalidRelocation). NONE and RELAX are skipped. R_RISCV_32/64 still go through the map.

Each pair names two labels in one section, so the difference doesn't depend on where the section is placed and S is the symbol's offset in its section.

Testing

Loaded headless with this dwarf_import in place of the bundled one (corePlugins.dwarfImport: false):

• Section addresses: x86-64 objects (-g, -ffunction-sections, COMDAT duplicates, zstd) have every function and data variable on its ELF symbol. This also holds with loader.imageBase = 0x800000.
• RISC-V: an ESP32-C3 C corpus (Espressif GCC 14.2, -O2 and -Og) fails before and imports after: 20 functions, 2 data variables and 4 types, with all addresses on their symbols. Names, signatures, locals and types match the same object linked with ld --no-relax. Line rows, ranges, location lists and CFA rows match the linked ELF's.
• No regressions: linked x86-64 PIE and non-PIE, and the ESP-IDF hello_world ELFs for the ESP32 and ESP32-C3, give the same results as [DWARF Import] Fix addresses for PIE and rebased views, relocatable objects and RISC-V objects #8654.
• cargo fmt --check passes. Clippy shows the same warnings as dev and none in the new code.

References: RISC-V psABI relocation table and ULEB128 note; binutils bfd/elfnn-riscv.c.